Re: [sfc] O-bit behavior in NSH spec
"Adrian Farrel" <adrian@olddog.co.uk> Sun, 26 February 2017 17:31 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBEB1295DF for <sfc@ietfa.amsl.com>; Sun, 26 Feb 2017 09:31:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wcdl3akr0-N0 for <sfc@ietfa.amsl.com>; Sun, 26 Feb 2017 09:31:21 -0800 (PST)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8820D1279EB for <sfc@ietf.org>; Sun, 26 Feb 2017 09:31:21 -0800 (PST)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1QHVJ2c032600; Sun, 26 Feb 2017 17:31:19 GMT
Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1QHVDHl032531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Feb 2017 17:31:18 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: mohamed.boucadair@orange.com, sfc@ietf.org
References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009E13FA3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0bb201d2893c$a8766460$f9632d20$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009E14ACB@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E14ACB@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Sun, 26 Feb 2017 17:31:08 -0000
Message-ID: <00bd01d29056$2372a9b0$6a57fd10$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKs4QfPsAfGu+IdxTavj2M4SM8+/wHdpbuiASPIQDcBAfo91Z+mwFNA
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22910.001
X-TM-AS-Result: No--8.940-10.0-31-10
X-imss-scan-details: No--8.940-10.0-31-10
X-TMASE-MatchedRID: O/y65JfDwwsn2WEbWzq9rSArD+K6XhnHQa2sDHLkQ06HwGEm+CpYGUJm fftVAWC9HRMPIwK2jF/XmhOmx9V2wnKgzS9kU8wEsyw+ZJnFumRWjiXAsVR2K0S/boWSGMtdUlx AXDKPA0zF0wMQNKBsD7xJvbAU9iUFaOHd6Wm/K5TmAId+2bAQwn0tCKdnhB58vqq8s2MNhPB9j2 GwzTE3vSq2rl3dzGQ16+SeJe1QBHxHSmUB+O8ak8zal0eKyqWbl4PbZq6AKH0mye5B6yF8TQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/drYugI6Am4wuzp_hqc_8pDYz6-k>
Subject: Re: [sfc] O-bit behavior in NSH spec
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Feb 2017 17:31:23 -0000
Hi,
> > In fact, I find that in addition to my previous points I see another
> > problem
> >
> > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC
> > OAM procedures, SHALL discard packets with O-bit set.
> >
> > SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable
> > parameter to enable forwarding received SFC OAM packets unmodified to
> > the next element in the chain.
> >
> > You cannot both have "MUST do X" and "MAY be configured to do Y"
>
> [Med] The initial SHALL is the default behavior. Adding "by default" wouldn't
be
> sufficient?
Then you mean "SHOULD" in the first paragraph and "MAY" in the second. I would
rewrite as...
SF/SFF/SFC Proxy/Classifer implementations that do not support SFC
OAM procedures SHOULD discard packets with O-bit set, but MAY
support a configurable parameter to enable forwarding received SFC
OAM packets unmodified to the next element in the chain.
> > Furthermore
> > For non OAM packets, the O-bit MUST be cleared and MUST NOT be
> > modified along the SFP.
> > which is not (I hope) to imply that the O bit can be modified on an OAM
> > packet.
>
> [Med] That's not the intent.
So...
The O-bit MUST be set for OAM packets and MUST NOT be set for non-OAM
packets. The O-bit MUST NOT be modified along the SFP.
Thanks,
Adrian
- [sfc] O-bit behavior in NSH spec Adrian Farrel
- Re: [sfc] O-bit behavior in NSH spec Dave Dolson
- Re: [sfc] O-bit behavior in NSH spec Adrian Farrel
- Re: [sfc] O-bit behavior in NSH spec Greg Mirsky
- Re: [sfc] O-bit behavior in NSH spec Dave Dolson
- Re: [sfc] O-bit behavior in NSH spec Greg Mirsky
- Re: [sfc] O-bit behavior in NSH spec Adrian Farrel
- Re: [sfc] O-bit behavior in NSH spec Greg Mirsky
- Re: [sfc] O-bit behavior in NSH spec Greg Mirsky
- Re: [sfc] O-bit behavior in NSH spec Adrian Farrel
- Re: [sfc] O-bit behavior in NSH spec Adrian Farrel
- Re: [sfc] O-bit behavior in NSH spec Joel M. Halpern
- Re: [sfc] O-bit behavior in NSH spec Ron Parker
- Re: [sfc] O-bit behavior in NSH spec mohamed.boucadair
- Re: [sfc] O-bit behavior in NSH spec Adrian Farrel
- Re: [sfc] O-bit behavior in NSH spec mohamed.boucadair
- Re: [sfc] O-bit behavior in NSH spec Adrian Farrel
- Re: [sfc] O-bit behavior in NSH spec Greg Mirsky
- Re: [sfc] O-bit behavior in NSH spec mohamed.boucadair